NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c++/1095

Text File | 1996-08-06 | 5.5 KB | 110 lines

Path: fido.asd.sgi.com!austern
From: [e-mail] (James Kanze US/ESC 60/3/141 #40763)
Newsgroups: comp.std.c++
Subject: Re: Rationale behind disallowal of non-const r
Date: 15 Apr 1996 11:47:11 PDT
Organization: GABI Software, Sarl.
Approved: [e-mail]
Message-ID: <[e-mail]>
References: <[e-mail]> <4jevb1$[e-mail]> <[e-mail]>
NNTP-Posting-Host: isolde.mti.sgi.com
X-Original-Date: 15 Apr 1996 18:44:34 GMT
In-Reply-To: [e-mail]'s message of 03 Apr 1996 09:24:06 PST
Apparently-To: [e-mail]
X-Auth: PGPMoose V1.1 PGP comp.std.c++
    iQBVAwUBMXKZsky4NqrwXLNJAQFvXgIAzVDquyMiPdJbg9092iV1R9orJvhuy/1a
    Op2T2iN0M+kYVL6DBq0ifc3U0Co/6Nooh4ii5OCf68CZJElx8hNxaA==
    =8CFr
Originator: [e-mail]

In article <[e-mail]>
[e-mail] (David G. Wonnacott) writes:

|> In article <4jevb1$[e-mail]> [e-mail] (Steve Clamage) writes:

|>    From: [e-mail] (Steve Clamage)
|>    Newsgroups: comp.std.c++
|>    Date: 28 Mar 1996 21:16:23 GMT

|>    In article [e-mail], [e-mail] (David G. Wonnacott) writes:
|>    >
|>    >I am looking for an explanation for the rationale behind the decision
|>    >of the standards committee to disallow the binding of a non-const
|>    >reference to an rvalue.

|>    The basic reason is that it usually is an error.
|>    ...

|>    Yes, there are times when you would like to be able to bind an rvalue
|>    to a non-const reference, since the only things you care about are
|>    sure to happen anyway.        ...           I believe the C++
|>    committee looked for ways to allow this binding of an rvalue to a non-const
|>    reference in cases where the results were what was intended, but failed to
|>    find a good way to define those cases.

|> What ever happened to "make it legal but recommend a warning?"  My
|> understanding of "illegal" is that the compiler should refuse to
|> compile the program.  I agree that the vast majority of occurances of
|> a non-const reference to an rvalue would be due to programmer errors.
|> But then again, so are many cases of "if (x=5) ...".

My understanding is that what happens in the case of "illegal" programs
is not defined by the standard.  For a certain category of errors, the
standard states that the compiler must issue a diagnostic; once that
occurs, you have undefined behavior.  (I think that we all would agree,
however, that it would be a pretty poor implementation that would go on
and do something bad having recognized an error.  But as some one once
pointed out to me in email: the `diagnostic' doesn't have to be on the
screen.  The implementor is free to document something to the effect
that `the diagnositic for errors requiring such in the standard is to
cause the light on the front of the hard disk to light up for 45
sec./Megabyte storage capacity.)

|> As I said, we make use of this all over the place, and its going to be
|> a real problem for us if this produces an error from most compilers.

|> We have a class for which (1) copying can be expensive, and (2) there
|> are some operations that extract information only after having a side
|> effect that can not be avoided (without copying).  Imagine if we could
|> do ++i but not i+1 for integers, and that copying them was expensive.
|> Suppose we we have a library that provides functions f1 and f2:

|>    int f1()         { ... }
|>    int f2(int &i)   { ++i; return i; }

|> (note that we copy the return values, but not the argument - it turns
|> out that we are more concerned with unnecessary copying for arguments
|> than return values).  The user of our library can then use y=f2(x),
|> and x will be incremented, and y will take on the new value.  We'd
|> like to let them use y=f2(f1()), to make y take on the value that is
|> one more than the value returned by f1().  The side-effect that was
|> performed on the object returned from f1 is lost, but we don't care.

|> I don't see any way of writing this without either (a) binding a
|> non-const reference to an rvalue, (b) forcing the user of our library
|> to set up an explicit temporary variable every time they use this
|> construct, or (c) giving up on avoiding this overhead and using call
|> by value for f2, or (d) doing something really brain-damaged like:

|>    int f2(const int &j) { int &i = (int &)j; i++; return i; }

|> But (a) is illegal, (b) is unreasonably inconvenient for our users,
|> (c) is inefficient, and (d) makes me queasy.

In the case of `int', I don't think there are any good choices.  But in
the case of `int', I don't think you need them.  For a user defined
class, I would certainly look into what could be done with mutable, and
declaring the parameters constant.
--
James Kanze         Tel.: [phone]        email: [e-mail]
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
                -- A la recherche d'une activitΘ dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:[e-mail]
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:[e-mail]
]